I’m not sure who said “Never complain, never explain” (Disraeli? Ford? Google’s not helping much), but it sure does apply to me, as I never heed the advice.
Today I posted the following on Twitter without thinking much about it:
“There is no Mobile Web. There is only The Web, which we view in different ways. There is also no Desktop Web. Or Tablet Web. Thank you.”
I certainly didn’t expect the enormous amount of retweets, which hopefully means that most people understood what I meant. But some didn’t, or didn’t agree with me. Which is a good thing, but only if my point is clear. So allow me to explain.
Most sites on the web are not built with specific mobile use-cases in mind. However, millions of people access these sites every day through mobile devices. They access a “normal” (whatever that means) website through their “mobile” device. In these cases, the presentation of the content on mobile devices is potentially important. As are the intrinsic characteristics of this content on the mobile platform; take image size as an example. Manufacturers cater to the users of “non-mobile” websites on mobile devices via things like zoom, which although inconsistent across devices, makes viewing most websites on a smartphone bearable. Developers can do their part by adjusting the served content or the presentation.
That said, simply adjusting the presentation of content or pieces of content on a website does not, in my opinion, constitute a “mobile website”. It’s a website for which the developers have considered the users of mobile devices and adjusted certain things accordingly.
As the venerable Thomas Fuchs points out, there are specific mobile use cases and thus mobile-specific websites or web apps. I agree. By the same token, there are websites and web apps which were designed with solely the desktop in mind (and oftentimes with a certain browser in mind). Yet we don’t speak of the “Desktop Web” when referring to these apps. Ironically, that’s exactly what we do with mobile.
To be honest, I can think of a few, but not many use cases of web sites or apps which are or should be exclusively mobile. It seems like the Mobile Web allows us to revisit all of the talk of inclusion, progressive enhancement and accessibility from years ago.
Much of this is semantics, I’m sure. I use the word “mobile” in my own job title, which obviously borders on hypocrisy. Why? Because if people understand the term this way, it’s easier for them to understand that part of my job is to consider users of mobile devices when doing design consulting for clients. So I use the term the way they understand it. It’s just not in line with how I see the Web personally.
Many developers also consider desktop browsers. And text browsers. And screen readers. And possibly print. Or e-books. Or whatever. Because the Web is about universally accessible structured content. Which data you get and use and in what form will depend on your device and your circumstances. Your context, if you are so inclined. And that will constantly be changing.
So maybe it’s a semantic distinction and I’m simply exaggerating like the American I am. But as long as there are developers selling and building completely separate mobile websites or iPhone websites or iPad websites where well-designed universal websites would suffice, it’s not only a semantic distinction.
No-one doubts the validity of ‘one web’ (and its principle of ‘thematic consistency’) if only because it means you can send or bookmark a URL from one device to another and know that the same content will be keyed off it.
But this does not mean that all users should be expected to use the same content regardless of device and context.
Your http://amazon.com/product/42 should indeed be the same as a German’s http://amazon.com/product/42, but that doesn’t mean that she wouldn’t rather see http://amazon.de/produkt/42 (since it’s priced in euros, describes the product in the native language, and invokes a much smaller shipping fee!).
In fact, the one-web axiom *requires* that if you to present radically different content for different users’ contexts, you should use a different URL for it.
My clichéd example is an airline web site. The home page for a sedentary user might present flight booking and corporate information; that for the mobile user a flight-checker and boarding pass barcode feature. Same brand, same standards, a completely different mix of content.
For a small business, catering for mobile users might mean no more than putting the ‘Contact Us’ page way up front on the mobile site instead of relegated to some distant footer menu. (It’s a phone, right?). Not a big deal, but a immediate commercial benefit from simply thinking about the users differently!
Of course, less relevant features/URLs should never be blocked from classes of user – you must still be able to see boarding passes on a laptop, and flight booking on a mobile, for example – but that does not mean they need not to be emphasized as much. After all, shouldn’t the UI make most easy the most likely user intent at any given point?
So anyway, the immutability of URLs is one thing – designing something suited to a particular class of users is entirely another. (And whether it shrinks to fit a 320px screen with natty CSS is entirely a third).
I’m not a fan of ‘One Web’ and only time will tell if the web goes that way.
One thing that most people advocating the ‘One Web’ seem to forget is history.
The evolution of the web before mobile devices (I’m going to call it ‘Desktop Web’) led to where we are today and, all of a sudden, it’s no good for mobile devices, with their touchscreens, no keys, taking one second to turn on and going with us to places we would never bring our laptop.
To me, the ‘One Web’ is proposing to redesign most of the existing desktop websites according to its principles, instead of building on top of what exists today. It sounds like a very unpractical proposal.
Beautifully said. And philosophical. I didn’t even have to read your explanation. A shame you had to explain it for some. Those two lines encapsulated everything :)
You may be thinking of ‘Never apologise, never explain’? – the Duke of Wellington
There are two reasons why I don’t think that “one web” is *always* the way to go. One is speed, the other is function.
There are lots of good reasons _for_ “one web”. Mobile devices are becoming ever more capable, mobile networks are becoming faster, and mobile browsing is becoming ever more common. From that point of view, the difference in user experience between mobile browsing and desktop browsing is diminishing. Many mobile browsers ignore media=”handheld” and use the regular CSS. With media-queries, we can make one single website that will redraw itself to fit any size display with a suitable layout. Having just one version of a website means no code forking, it means no duplicate content, it means much less work for webbies to maintain two separate sites.
But…
While that’s true for a lot of sites, it doesn’t hold for all, and particularly it doesn’t always hold for large sites. It works for a site like this one, which is lean and simple and has essentially just one function. But for larger and more complex sites, there are two factors that mitigate against.
1 – Function. A lot of people do distinguish between online things they’ll do from a mobile, and things they would prefer to do from a PC. For example, I would hate to type a long reply like this in using my mobile, because it would take about an hour. Complex spatial work is best done on a big screen with a mouse. But other tasks are particularly suited to people who are on the move with just a few minutes to dip in and out. That’s particularly true for travel industries (when people are literally on the move and need to check travel plans) and physical retail. Offering a dedicated mobile version of the site that prioritises those features can make a huge difference to people’s experience and success rates.
2 – Speed. While mobile browsing has got better, it often still lags a long way behind desktop PCs on a broadband connection. Heavy websites with complex designs and lots of scripts and images are a PITA on most mobile browsers. While media-queries can alter the display, they can’t so easily stop you from needing to download massive jQuery libraries and the like. Offering a stripped down version of the site that leaves out this incidental cruft can compensate for the much slower mobile browsing experience.